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INTRODUCTION 



Problem 

As military hardware becomes increasingly complex and costly, the suitability of 
using the real equipment to meet all maintenance training requirements diminishes. 
Nevertheless, student technicians need to learn how the equipment normally responds to a 
wide range of conditions, and they heed to experience abnormal responses and indications. 
As they develop a good^tSderstahdihg of equipment brgahizatibn and functions, they need 
to develop and practice their skills in logical fault identification arid isolation. 

The limitations imposed by the real equipment in m^tj^^ 
familiar dries. If the training command is fortunate enough to receive appropriate models 
of the real equipment^ along with adequate spares, its maintenance problems are greatly 
aggravated by the use of the equipment in the training environment. As a training 
vehicle, the real equipment is limited by (1) the retirement that the instructor insert 
practice malfunctions, (2) the difficulty of capturing data regarding student performance, 
and (3) the cost of providing individualized assistance arid guidance to each student. 

Special-purpose simulators relieve some of these prpHerns^ but they too tend to be 
'^costly and difficult to maintain. Thus, the need exists for a general-purpose maintenance 
'trainer that can be tailored Via software to function as a trainer/simulator for a wide 
range of equipments 3nd electronic systems. A laboratory model of a Generalized 
Maintenance Trainer Simulator (GMTS) has been developed and field tested (Rigney, 
Towne, Moran, ft Mishier, 1980). 

Background 

System Description 

The GMTS is a computer-based simulator that automatically selects malfunctions and 
displays high-resolution color images of the equipment. The student can rapidly access 
close-up views of any section of the equipment and can iriteract with the displayed 
switches^ by touching desired switch setting? with a. smaU stylus. Upon sensing such an 
action, GMTS determines what switch and setting have been touched, determines how the 
indications on the current image would be affected by that action, and automatically 
displays a new image. In a similar manner, a student may cStt up views of an equipment's 
test points, touch those of interest, and observe the indications that test equipment would 
produce. In effect, the student has the same opportunities for operating aid tro^leshoot- 
ing the simulated equipment as he does with the real equipment. Ultimately, the student 
may identify the element that he suspects is Jaulty and "replace" it or he may give up. 
GMTS recorcfe ad! student performance for subsequent analysis arid reporting. 

The GMTS must not be confteed with a Jrairier that attempts to represent a larp 
class, or family, of equipments that share a common purpose. While such generic trainers 
may have great potential for instructing new technicians about an entire cl^s of 
equipments, they nevertheless simulate the characteristics of one class. While the 
physical configuration of the GMTS is fixed* a subject matter expert (SME) can cause it in 
principle to simulate any target equipment or system. If desired, the GMTS can also serve 
as a generic traner by simulating a real or hypothetical examplar of a family of 
equipments or systems^ 

Previous field tests of a laboratory model of GMTS demoratf ated the potential of the 
concept* but the laboratory model was limited in the following ways: 
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1. High-level programming languages were unavailable, so the executive programs 
were written in assembly language. The software was thus committed to a particular 
microprocessor , and programs were not easily expanded and revised. 

2. Standard peripheral interfaces were unavailable, so they were custom engi- 
neered. The reliability arid maintainability were poor* arid the unit could riot be replicated 

a low cost. <3 

5 3. The commercial suteystems comprising the trainer/simulator became essentially 
obsolete during the final development year. Smaller, cheaper, and more reliable 
coun terparts became available. 

Many of the functions that instructors would typically perform in the instruc- 
tional environment were performed by the contractor. Additional documentation and 
Utility programs were required if the trainer was to be turned over to a training facility. 

* System Development 

The basic conrept : 6i : GMTS emerged after many years of efforts to represent 

complex physical systems and human behaviors in a form conducive to machine proces- 
sing.. Whereas most research in computer-aided instruction derived from questions about 
the nature of learning and the structure of knowledge, this early work was concerned 
solely with characterizing the operation of a physical system. The result was an explicit 
arid general taxonomy of the nature of normal and maJfurictioriirig systems. These 
represent at ions, in the form of computer programs^ expressed the general process^, both 
manual and cognitive^ ^rformed by a maintenance teSrucian^ and the types of states in 
which ^systems can _exist _i The necessary inputs to these programs represented the data 
necessary to characterize any particular system. 

Through the mid ISSbsj this research was concerned with modeling corrective 
maintenance performance arid predicting associated repair tim». Sueh modeling required 
(1) a model of ari "ideal" troubleshooter, (2) a theory 6^ hum an troubtefiootirig behavior, 
and (3) a general-purpose repr^eritation 6^ to be maintadned. These 

requirements are described in the following paragraphs: 

1. A model of an ideal troubles faooter . This model was based upon a Bayesiari fault 
isolation process (Rigney, Cremer, Towne, & Bond, 1967). In this process, .subjective 
probabilities are associated with each element in a set of hypbth(M« # The initial 
probabilities of the N elements may either be based upon available reliability data or all 
rriay be set to 1/M. 



The_Bayesi^ model sdects as the next test the one that is expected to yield the 
maxim um uncertainty reduction, which is a function of the a priori probabilities arid the 
information value of each test. - 

A second computer program (Towne, 1968; Towne & Mason, 1967) was developed to 
generate the time required by a human technician to isolate faults, if he followed the 
Bayesiari ^gbrithrri. . This program automated the application of classical industrial 
engineering techniques to produce a time "staridarcf 1 for a defined work method. A 
limitation of that technique was ihat^rily manual time could be projected. At present, 
this approach is being generalized to include cognitive time. 

2. A^theory of human troubleshooting behavior. Using the Bayesian process as a 
baseline, which, incidentally, reduces the "half -split" technique under certain conditions* 
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an effort was made to ascertain the extent of conformance between this model and human 
strategies. Specifically, we investigated (a) whether technicians with better data (i.e., 
better understanding of the system in question) were more Bayesian, ana (b) whether they 
would appear more Bayesian if their data (rather than the true symptom-malfunction (SM) 
data) were used to drive the model. 

Approximately one-half of the technicians studied (N = 39) were found to be generally 
Bayesian when using their own SM data; the other half were not. However, even the 
"Bayesian" technicians were only about 30 percent as efficient as the Bayes model using 
true SM data. 

The correlation between the accuracy of subjects' SM data and their tendency toward 
Bayesian troubleshooting was a moderate r = 0.55. Whenever subjects erred in generating 
SM data, they generally made several more irrational non-Bayesian actions. 

3 a general-purpose system representation. The reseaf cntdescribec' above motiva- 
ted an effort to develop a generaUzed and machine-computable technique for representing 
a real system. Consequently, a program was developed (Rigney & Towne, 1972, 1977) that 
accepted a straightforward itemization of system elements indudng general-purpose 
blocks, switches, relays, switch wafers, signals, indicators (including test points), and 
modes. 

This system was applied to the AN/SPA-66 radar repeater, producing a system 
description involving 38 network blocks, 51 indicators, and 17 mode switches. The 
program was able to generate correct SM data in any mode of operation. These SM data 
were subsequently processed to produce Bayesian troubleshooting strategies and to 
evaluate human-generated strategies. This program was then employed to generate 
student-computer dialogues through a teletypewriter connected by telephone to a time- 
shared computer (Rigney & Towne, 197*). The computer- generated statements were 
produced by combining fixed statement patterns with text from the equipment-specific 
database. An example statement is shown bc'ow: 

YOU SHOULD KNOW THAT <system element name> CANNOT BE FAILED 

BECAUSE YOU OBTAINED <symptoms> WHEN YOU PERFORMED <test name>. 

A relatively wide variety of statement forms yielded the ability to make suggestions, to 
correct conceptual errors, and to respond to various calls for assistance. 

By the early 1970s, minicomputers were available that were capable of executing the 
GMTS program and controlling other peripherals. In 1978, the first informal field test of. 
the GMTS stand-alone configuration was conducted when the trainer was applied to the 
Fleet Communications System, a large multi-equipment system for radio communication 
(Rigney, Towne, King, & Moran, 1978). In that test, 20 class "A" ^chool students worked 
on 35 simulated troubleshooting problems. Results indicated that the trainer offered 
realistic, accurate, and efficient practice and that the learning transferred well to the 
read equipment. 



In a second field test, the GMTS was applied to an entirely different target system 
than that used in the initial test; namely, the AN/SPA-66 radar repeater that had been 
simulated in the early research (Rigney, Towne, Moran, & Mishler, 1980). The data base 
for this test was prepared by two technical experts who were concerned only with 
supplying the specified data in the required formats. A relatively short field test 
followed, involving 10 subjects, each attempting to isolate 33 simulated malfunctions over 



a ISrhour period. Following this practice phase* the students were tested Using an actual 
AN/SPA-66 with actual inserted malfunctions. As with the first test* results were 
generally positive, especially in relation to success in the test phase using actual 
^ prn ^nt» ^5?^ ?^L_^?^Pl_^ ^9^^?T» the prirriary value of this test was 

£to demonstrate that technical content experts can apply GMTS. 

Having passed those early tests, the time had come to compare the training 
effectiveness of the GMTS to that of real equipment. First, however, the laboratory 
model had to be Upgraded, reprogrammed, arid extended to allow a realistic irilplerrierita- 
tion in the training environment. 

Purpose 

The purpose of the research described here was to improve the laboratory model, 
maximize the transportability of the software to new microprocessors, and augpnent the 
software to allow Navy instructors to manage the system. \j' 

The specific objectives for improving operational effectiveness were to produce a 
smaller, cheaper, and more reliable configuration that could be easily replicated and 
maintained by others; The ease of implementing the software on new microprocessors 
would [be maximized by feprogfamSirig th^^MTS 

language; UCSD Pascal [C I? UC5D Pascal" is a trademark of the Regents of the University of 
California), and by producing a complete software documentation package. 

Finally, a number of extensions to the existing repertoire of instructional facilities 
were specified. The primary thrust of these extensions was to increase the extent to 
which the instructor could shape the student-trainer interactions arid retrieve student 
performance data. 



APPROACH 

Training and Simulation Characteristics - 
Training Objectives 

The specific ^ training objectives to be achieved using GMTS _may vary greatly ^ffom 
one application to another. The general objectives for which the trainer was designed are 
as follows: 



1. To enable the student to become proficient in determining the state of the real 
equipment being simulated; that is, whether the equipment is operating normally, 
operating within the tolerances arid limits of fully bpera^brial Units, or is riot fully 
operational. For equipments not fully operational, the student will be able to identify 
normal and abnormal operating modes to determine the extent to which the equipment is 
degraded^ 

2. To enable the student to become proi/cient in setting up and interpreting front 
panel tests. This includes establishing desirdS modes of operation and interpreting the 
normality/abnormality of indications exhibited in these modes. * 

3f. To enable the student to become proficient in the selection and use of test 
equipments Proficiency should include identifying arid attaining prime equipment modes 
that effectively exercise the functions being considered, selecting test points that will 



reveal the states of the prime equipment in these modes, and interpreting the indications 
obtained. . 

Simulations of prime equipments will usually riot include full simulation of general- 
purpose test equipment. (Such exercises could, however, be provided by the trainer in the 
future.) The training ob[ectives related to use of test equipment focus bri choice of test 
points to be .sampled, choice of prime equipment modes during that sampling, arid 
interpretations of test results. 

Training Exercises 

The training exerdse explicitly addressed by GMTS presents the student with an 
initial st^ement of a mj^unctibtfs gross effect(s) and requires that he employ trouble- 
shooting skills to isolate the source of the problem, ft logic diagram of that process is 
shown in Figure 1. - 

GMTS can also provide other types of part-task exercises, such as |fie following: 

1. Equipment familiarity . Following written guides, the new technician can set up 
the equipment in major operational arid maintenance modes to become acquainted with 
norm^ system operation. This exercise closely resembles an exercise commonly 
conducted with the real equipment in many military electronics schools. 

2. Set-up exercise. Working -without aid of detailed instructi ons , the student can 
practice achieving modes named by the instructor. . If desired, the instructor can provide 
some selected readings at various test points, thereby allowing the student to determine if 
his set-up is correct. Alternatively, as a test, the student can turn in his readings at 
selected test points. 

3. Test point location exercise. The student can locate arid sample the values of 
variotB test points designated bj^he This exercise would provide practice in 
locating test points by their designations in the technical manual. 

4. Symptom evaluation exercises . Under various malfunction randit^ons eSabiished 
by the trainer (under instructor control), the student can extract symptoms information 
from various iridicatbrs arid test points in designated modes, the exercise consists of 
assessing the normality of each observed indication. 

5. Functional assessment exercises. This exercise is concerned with establishing 
relationships between observed indications and possible causes of these data. In one form, 
the student simply proceeds from exercise four, above, to itemize the possible causes of 
the observed abnormal indications. The instructor could then eyalu^e thKe lists 
iridividually* or in class. In an a^ernate form, the student predicts the responses of 
various indicators in known malfunction conditions after studying the technical document- 
ation. He then operates the trainer to determine if his predictions are valid. 

These simple exercises can be produced by an instructor using the standard instructor 
utility functions that give control over selection of the malfunction, if any, and order of 
problems. 
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Initiate problem: 
Select malfunction 
Present operator complaint 
Display top-levri diagram 



. Accept and interpret 
student input 




Present image 
simulating effects 
of student action 



Convert touch pen into 
Test equipment probe 



Replace selected clement 




"Scrry; continue" | 



Record 

performance data 




Figure !; Genferal logic cfiagram of GMTS trbubleshobtirig exercise. 



Problem Identification and Selecti on 

The repertoire of rhalf unctions to be presented by the trainer is determined by the 
date base preparer. GMTS can simulate any malftm^on that exhibits its symptoms in a 
consistent fashion (intermittent faults are hot permissible), A cascading fault, which in 
the real equipment would cause one or more other faults, is permissible^ The s^t pi 
resultant faults, however, along with, the catling fait,^nust ail be described as a single 
"malfunction syndrom 2?' by the data base preparer,^nd must all be replaced^t one time 
by the student, That is, tte system will not simulate the _ Jen^n^ con-ectidri and 
subsequent recurrence of resultant symptoms if the causing failure persists. 

The executive program determines the next problem to be presented for each student 
acoirding jo instfuctor^s^pp^ specifications. During dat^ base ^vdopmc?nt, the 
iretructor supplies the practice arid test problems to fee presented and ^ocat« these 
problems into sets called poqis^ At one exti'eme, one problem coultf be placed in each 
pool, achieving a fixed sequence of j>r«^^on. A^ 

could be placed in one psol. achieving complete random More 
commonly, instructors assign problems to pools that relate to planned lectures. 

At any time during a course, the instructor may key in the highest pool number f rom 
which problems may be selected* thus assuring that students receive only problems that 
are appropriate to the progress of the lecture seri«* ' " 
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Student-trainer Interactions 



Conventional computer-assisted instruction typically proceeds through cycles of 
content presentation, question presentation, answer processing, and subject-matter 
routing. GMTS currently relies on external means, such as lectures and text books, to 
present content such as theory of equipment operation. The trainer then provides the 
student with a means for (1) exploring a complex system by operating it in its-normal 
state and a variety of abnormal states and (2) developing and refining a logical fault 
isolation process as a function of increased understanding of symptom information related 
to modes and malfunctions. - . 

Hardware 

The GMTS (Figure 2) consists of three off-the-shelf commercial units: 

MICROFICHE 



CRT 



TOUCH 
STYLUS 




Figure 2. GMTS training/simulation station. 



I # a Terak 8510a computer, with 28K words of 16-bit RAM, a reai-time clock, a 
graphics and alphanumeric CRT, an 8-inch floppy disk drive and keyboard (used only by 
the instructor), and a second floppy disk drive (Terak $512). 

2. A Bruning Model 95 .microfiche projector with an RS232-C computer interface 
and 1,800-image capacity (30 fiche x 60 images per fiche). 

3. A Science Accessories Corporation Graf pen with ah RS232-G computer interface 
and 1mm resolution. 

The three major units are plug compatible; that is, they are connected without 
electronic modification via standard cables. The only hardware modifications were to 
remove the manual ke^oard from the Bruning 95, the two Graf pen sonic sensors from the 
standard mounting, and the Terak CRT from its L standard cabinet. The Units were then 
installed in a modified Emcor Data Desk, which provided jt loekable bay for disk drives 
and other electronics, ample working space for handling and studying technical manuals, 
arid ah integrated^ ehdosed Unit. 



This configuration provided two displays: (1) the computer- driven CRT used 
primarily to interact with the student regarding instructional and tutorial matters and (2) 
a rear-projected microfiche screen for representing the real equipment. 

the Graf pen provides the means of input to the trainer, and all student actions are 
made by touching the CRT screen, the microfiche screen, or the command menu with a 
stylus Whose position can be sensed by the computer to within 1mm accuracy. The CRT 
acts exclusively in an administrative, vice simulation, capacity. It displays statements 
and questions to (1) identify a student at the start of a session, <2) allow the instructor to 
designate the latest lecture completed, (3) initiate new problems, (4) execute replace- 
ments requested by the student, (5) verify current test equrpment sdections and 
connections, and (6) handle termination of problems and sessions. The microfiche screen 
acts exclusively to represent the real equipment. 

At the initiation of a new problem, the CRT displays an operator's complaint, such as: 

THE MALFUNCTION LIGHT IS ON, 

which is similar to a failure report initiating a real repair effort. Simultaneously, the 
microfiche screen displays a "top level" diagram that exhibits all equipments and 
peripheral systems£that the student can manipulate or examine. The student obtains 
closer and closer views of the equipment by touching the area of interest with . the 
acoustic stylus. This incremental "zooming" normally involves one to three steps, which 
result in a close view of a relatively small portion of the entire system. Whenever a 
dose-up image is shown, front-panel indicators will appear identical to the ones on the 
real equipment, given the mode of operation and failure condition, if any. 

The student changes switch settings by touching the panel, as shown 'in Figure 3. 
Whenever the student touches a new switch setting or test point with the stylus, the 
computer commands the microfiche projector to retrieve and display the image that 
reflects the action taken. - 



Student Touches 
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Original Image Next Image 

Figure 3; Setting switches in GMTS. 



the command menu, shown in Figure allows the student to interact with the 
executive program. 



Higher 
tevel 



Replace 



Test 
• ■ 

Equipment 



Interpret 
T/E Reading 



Redefine 
•_ 

Ref. Point 



Problem 
Solved 



Stop 
Problem 



Renew 
image 



Figure U. Command menu. 



The commands and their effects are as follows: 

1. HIGHER LEVEL. Students touch HIGHER LEVEL if they want to see the next 
less detailed picture in the system's hierarchical structure. This was the picture from 
which the currently projected section of the system was selected. 

2. REPLACE. Students touch REPLACE if they want to replace the section of the 
system currently displayed. Subsequent indications will reflect the success of this action. 

3. TEST EQUIPMENT. Students touch TEST EQUIPMENT if they want to perform 
test equipment readngjs). The CRT displays a list of all test equipment defined, and the 
test points to which they are ^currently connected for "~ — " if riot connected). For 
example, the following display shows that a multimeter is connected to test point 31* on 
card 1A1A2: 



CONNECTED TO: 



♦OSCILLOSCOPE 

♦MULTIMETER 1A1A2 31* 

Touching the asterisk (♦) next to the desired test equipment name in effect causes 
the touch stylus to become the probe for that type of test equipment. Touching a 
displayed test point produces the test-equipment reading on the microfiche screen and the 
test point designation bh the CRT. 

H. INTERPRET T/E READING. Students touch this command if they want help in 
determining whether the test equipment reading currently displayed on the microfiche 
screen is normal or abnormal. This support is unavailable in test mode, and its use is 
recorded with the student's performance data. 

5. REDEFINE REFERENCE POINT; Students touch this command if they want to 
repeat the calibration of the currently displayed image by touching a special symbol in the 
corner of the image. 

6; PROBLEM SOLVED. Students touch this command if they believe they have 
restored the simulated ^mpmesrvt to normal operation. h\ practice mode, students are 
allowed to continue a problem that has hot, in fact, been solved. In test mode, this v 
command terminates a problem; 

7. STOP PROBLEM, this commands the trainer to abort the current problem. 

8. RENEW IMAGE. Touching RENEW IMAGE causes the microfiche projector to 
reproject tfe current image in case of poor registration. 

Software 

System Software 

The sy&em software described in this section consisted of computer programs 
written in UGSD Pascal. Particular advantages of developing programs in UGSD Pascal 
are listed below: 

U Pascal is highly standardized, maximizing ease of augmenting and maintaining 
programs. 

2. Pascal was specifically developed for ease ofc prb^am tr^portability (i.e., 
impl»nentatiori on other computers). 

3. The structured nature of the langiage tends to promote well organized programs 
that are easier to develop ar^tfooimerit. 

The UCSD Pascal operating system offers a complete filing and editing facility, 
which is used extensively during data base entry. 

Instructional and S imulation Softw a re 

The computer programs that control the (on-line) delivery of instruction and 
simulation are of two types: 
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1. Simulation programs that sense arid interpret student, actions, determine the 
effects of those actions in the real equipment, and respond by altering the P res ; n ^^ n -^ 
the equipment on the simulation screen. The major components of simulation control are 
listed below: ; 

a. Student action interpretation-Sensing and interpreting the significance of 
an action by the student, as indicated by a touch-pen strike. 

b. State evaluation-Determining the state of an equipment (including test 
equipment) from data describing a malfunction and the current mode* 

c. Selecting the appropriate microfiche display. 

2. Pedagogical programs that select problems, provide symptom assessment assist- 
ance (INTERPRET T/E READING), record performance data, arid offer other instructional 
functions. 

Figure 5 illustrates the general organization of the GMTS system software, arid the 
appendix provides summary program documentation. 



Specific Eqoipment Data Base 

• ^^chine-readabie data 

- Normal operation 

- Malfunction effects 



Color Photographs 

- Eront panels _ _ 

- Test equipments 

- Eternals 



Instructor Utilit y Programs 

• Problem selection 

• Course set-up 

• Progress summaries 



Executi v e Program 

• Simulation 

• Pedagogy 



Specific-Student Data Base 

• Progress (prb^lems/time) 

• Measures, of effectiveness 

• tast-probiem details 



Figure 5. System software structure. 




Software forBata Base Development 

After organizing the alphanumeric ^data to desCTibe the equipm«it, the SME keys the 
data in at a keyboard that plu^s into the ^omputer^ The resulting cteta file, may 
subsequently be printed and edited, using system software provided with the system. 

When this data file is prepared, a utility program is executed that reacfe in tte- source 
data^ converts it to a format that can be more rapidly accessed by the training program, 
and checks for a number of possible data errors. The resulting file is then copied to 
diskettes for use by students. If desired, the data base preparer may execute a second 
utility program to verify the data base^ Jfns program operates on the data base exactly 
as does the training program, except ttet it accepts keyboard input only and generates 
CRT output only. Its purpose is to allow the data base preparer to run the simulator prior 
to producing the microfiche. 

The third utility program used to support data base development is concerned with 
defining the various points on each microfiche imagti. > This program displays each 
microfiche image, L and the SME can designate subpictures, test points, and switch 
positions with the touch pen. As this is done, he identifies various points by touching key 
words and numbers displayed on the CRT. At ^he completion of this process, a data file ik 
automatically produced to allow the trainer/simulator to interpret each student input. 

Instructor Utility Progams 

instructor utility programs are provided to Establish problem selection constraints, 
set-up new classes^ and produce class progress summaries. The sp^^-purpose utilities 
a^ifable to instructors are as f dHbws: 

1. ADD STUDENTS;. This utility is to prepare student diskettes for hew 
studalt data. It reserves space on each diskette for student data and heads that space 
with the new student's name. 

2. GET STUDENT DATA. This utility^ copies student performance data from each 
student's diskette onto a class master diskette. 

3. PRINT STUDENT DATA. This utility prints out a record of each student's 
performance data in the class to date, providing instructors with data bh individual 
student performance. „ 

4. SET PROBLEM SEQUENCE. This utility allows instructors to establish a newly 
required sequ«iee of problems. ^ 

5. SEE PROBLEM SEQUENCE. This utility allows instructors to' review the 
prescribed sequences of individual problems or prbblen tools.; 



Simulation Data Base 
Preparation 

The simulation consists of (1) the alphanumeric data base required to compute 
responses of the equipment to student actions and (2) color microfiche to simulate the 
appearance of real equipment; The alphanumeric data include the following: 



1. Names of replaceable elements. 



2. Operators failure complaint (to start each problem). 

3. Names of test equipments available. 

4. Names of test points (for verification on the CRT). 

5 # Lists of allowable test equipments for each test point. 

6. Names of switches and settings. - 

7. Initial settings of each switch (by problem if desired). 

8. Modes of operation. 

9. Symptom-malfunction relationships by mode. 

♦ 10. Required equipment mode for replacement (usually deenergized). 
Hi Index to microfiche images. 

In addition, a "map 11 of each section of the equipment is created by running the utility 
program XY (see appendix). This map is a list of Cartesian coordinates that identifies 
each active point (be., one which may be touched by the student with the input stylus). 

With this rich base of textual and logical data, GMT S is able to do the following: 

1. Select an appropriate malfunction in accordance with the instructors plan and 
the student's progress. 

2. Retrieve and (fisplay the operator's complaint to initiate the problem. 

3. Project the "top level 11 diagram of the systeiji. 

U. Display successively closer views of the area of the real equipment indicated by 
the student. 

5. At the close-up level where symptom Iriforrnaction becomes L visible, compute the 
symptoms evident at each indicator in the currently viewed section of equipment and 
project the image containing thk^e symptoms. * . 

5. Respond to touch inputs a? switch settings by recomputing all symptom data and 
* projecting the Image reflecting both the switch setting change axvd the new symptoms, if 
any. . . • ■ ■ c 

7. Rttpond to requests for replacement by subsequently producing normal ihdica- 
tions, if the replacOTi«tt was correct. . - 

3* Respond to requests for symptom interpretation assistance, if not in the test 
mode* . ' 

9. Record student performance data, including errors and time. 

% While this data base is necessarily complex arid somewhat voluminous, an SME can 
learn to develpp such a file in 1 or 2 weeks. The only knowledge necessary is a thorough 
understanding of the acppmmt to _ 
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A complete guide has been prepared that describes the data files in detail* as well as 
the process for developing them; this document wi ll b e published separately as a GMT5 
User's Manual. The steps used in assembling the:information are described below: 

1. Define scope of the training simulation (syste m analysi s) . The Stqpe of the 
simulation is determined by the modes in which that hardware is to be simulated. The X 
modes are defined in a listing of all prime equipment and test equipment, including any 
peripheral equipment that will be either operated or observed by the student as he 
troubieshbots; 

2. Analyze Gaining requirements. This step coasts of^ d^ermi^rang the level to 
which maintenance is performed (i.e., will modules, boards, or componOTts be repined?}, 
defining the prerequisite skills of entering students, defining terminal training^ objectives, 
arid, finally, selecting malfunctions for simulation that will best offer the -practice 
necessary to attain those objectives. 

Careful consideration should be given to student skUls_necessary for troubleshooting 
and to the mmnten^ice philosophy of the equipment. These impact the depth of 
knowledge the student must possess to repair the e^pmerit arid the choice of effective 
practice problems. The two jjenerai ^ their 
instructional value in illustrating a function of the unit, and those selected as a result of 
their incidence in the fleet. 

3. Define the equipment states to be simulated . The elements defined by Step 1 
form a first level of subdivision of the entire system or equipment. Each of these 
^ements must father subdivided; Nearly any s^terh can be viewed as consisting of no 
more thOT six to ten demente. Turthe^ore, even large, complex, multi-equipment 
systems rarely require more than three to f our levels of <Kvision to reach meaningful 
groupings ^of dials, indicators, or test points. This means that the ^er wiU normally be 
able to access an area of current interest with only one qr two changes of level; each 
accomplished by touching the stylus to the area of interest on the projected image. 

/ Within each area of interest, the data base preparer must decide how many discrete 
positions of continuous controls and continuous indicators (such as meters) will be 
simuiated;_ Gener^iyy-three to five potions are adequate; At this step, the data base 
preparer entnrierates the number of images required to represent jthe modes^<^6perati6n 
defined in step one. If the number is exc^ive (oyer 1,800 i^jng current micrograpKcs 
hardware), one must either reduce the number of mods to be simulated or divide the 
equipment into smaller sections. 

4. Photograph the real equipment in each state and produce color microfiche. Two 
types of pictured are required to support the simulation: (a) pictures of equipments or 
portions of Equipments, which serve as pathways to more detailed subpictures, land (b) 
pictures of aH the stats defined for sections with controls and/or indicators. The f ormer * 
termed intermediate : Jcenes,^re ^bften produ^d^wa a ^OTmbitiatiOT of photographs and 
graphics art* The latter, tenned muiti^ate^ 

picture list as a guide. The picture list defines each possible ^ state (both n qr m d and 
abnormal) of each multistate scene, in terms of the control positions and indications 
required. Color 35mm slides are then taken of each equipment state and sent in for 
commercial microfiche production. 

5. Encode the list of states, index to microfiche images, and symptomatic function 
data, In^genera|r^Ic^ 

due to a fault, and (b) equipment now f unctioning property, since the student has replaced 
the faulty element. 

Q -CO 
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The - data base preparer first collects the data required to simulate the normal 
operating equipment. For each section of the system, the normal pictures are noted, and 
the switch settings required to produce each picture are listed. Next, the data base 
preparer specifies the effects of each malfunction by identifying the sections of the 
system, including test equipment, that are affected by the malfunction. 

The amount of data listed is greatly limited since (a) only exceptions to normality are 
identified and (b) for any one section, many malfunctions will cause identical abnormal 
symptoms. This commonality is exploited to minimize the data required to characterize 
the effects of a malfunction. 

In addition to the data described above, the preparer also inputs such information as 
initial switch settings and test point constraints (i.e., what test equipment can be used on 
various test points?). 

6 Key i n the data and check the resulting file . The information compiled in Step 5 
is keyed in at a trainer station and recorded on a diskette. Then a program is executed 
that examines the data, checks for omissions and contradictions, and reformats the data 
in machine-readable format. After any noted errors are corrected, a second utility 
program is executed to identify the locations of all points that the user may touch with 
the touch pen. This is accomplished by touching each ••active" point in the picture and 
then providing the associated subscene number, switch number, setting number, or test 
point number. 

The data base structure is flexible, and it may be desired to carry the fidelity and 
detail much further in some areas than others. Also, there are often many opportunities 
for greatly paring the number of system states simply by eliminating redundant modes, 
bands, etc Such reduction caa often be done without artificially simplifying the 
troubleshooting task. For example, if a transmitter operates in 32 bands, the simulation 
may only need to implement two Or three. 

. A functional representation of the graphic portion of the simulation data base is 
presented in Figure 6. While this figure happens to represent a system with three levels, 
there may be up to ten levels of hierarchy employed. The system software does not 
require a- uniform decomposition of subelements. Thus, some equipments in a system may 
require four of five levels and others, only one or two. Finally, the system software 
imposes no constraints on the contents or layout of each .microfiche. Thus, most rapid 
response can be achieved by grouping together all images for a particular equipment 
section. 

The alphanumeric data base is written to a single 8-inch diskette, along with a copy 
of the system software. Thus, the trainer can be changed to simulate a different 
equipment by changing the microfiche cassette and the data base diskette. 
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The AN/WSG-3_is_a- transceiver that is fhe_Jtgyw_ component of a fleet satellite 
communication (SATCOMM) system. The SATCOMM system includes, b&ide the 
AN/WSC-3, two hennas, amplifies, relays/ a t^etype^ and several minor components. 
The simulation data base was developed for the entire system, and the largest part of it 
related Whe AN/WSC-3 itself. : 



training for the maintenance of the SATCOMM system is provided by, 
the Advanced Electronic Schools Division (AESD) of Service School Command, San Diego. 
This school was theN^stted-f cr developing the data base and for gathering data on thp 
supportability of the GMTS. Six advanced development GMTS units were* constructed, 
four of which were installed in the AESD school for data-base development and for 
experimental use by students^The results of these two efforts will be the subject of a 
future report. 



GMTS respond time to touch inputs varies according to touch location. Response to 
touching the CRT or command menu occurs within 0.1 second. The trainer responds by 
altering the CRT display, updating the simulation display, or* if the touch was not 
identifiable, emitting an audible beep. 



Responses to inputs on the microfiche screen involve a compute delay plus image 
change time, the compute delay, which varies from one data base to another, ranges 
from less than 0.001 second :o approximately 5 seconds* with an average of approximately 
1 second. Image change time varies from approximately 1 second, if the new image is on 
the same fiche as the current image, to approximately 3 seconds, if a fiche change is 
required. 

Calibration 

Although the touch pen inputs are detected to 1mm precision, the student is required 
only to touch the pen within a reasonable proximity to the desired point; GMTS interprets 
touch inputs by comparing the detected touch location to a set of defined, stored points. 
This process, however, requires a means for correcting for the following random hardware 
variations: s 

1. Variation in location of the CRT, touch-pen sensors, and command menu (from 
one training unit to the next). 



2/ ^5ly^to-day variation of display location on the CRT. 
3. Day-to-day variation in touch-pen operation. 



These variations are measured eaditime a unit is energized. The calibration consists 
of touching displayed targets on the CRT and command menu, thereby identifying their 
exact location. This also vertfia that the touch-pen arid CRT are functioning correctly. 

A more bothersome variation is thepositibnal error in projecting microfiche images. 
As a result of the high magnification employed (22X), very small mechanical deviations 
result in errors as large as 0.5 inches in absolute position oi an image on the screen. 
Normally, this error would not cause difficulty; however, some images may contain test 
points or switch settings that appear Jess than 1 inch apart and could be confounded. To 
overcome this variation, each microfiche image contains a small "bulls-eye," called a 
reference dot, in the lower right-hand corner. Each time a new image is displayed, the 
user first touches the reference dot. The GMTS then corrects all subsequent user inputs 
on that image by the calculated error offsets in the horizontal and^vertical dimensions. If 
micrographics projectors new under development can deliver repeatable image position 
with errors Jess than 1/16 inch, ;t here will be no need for the reference dot. 



The error correcting performed by the executive program allows the positional data 
stored on diskette to be independent of the particular unit that will employ it. 
Furthermore, it allows free substitution of subsystems (touch pen, microfiche projector, 
CRT) without upsetting the reliability with which user inputs are interpreted. 
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RESULTS 

Operational Effectiveness 

The upgraded configuration of GMTS is smaller, lighter, and more economical than 
the laboratory model. While some aspects of user acceptance and training effectiveness 
tan be drtermjnedoray after more extensive experience in the training setting, it appears 
that the system's response ttime, ^reliability, maintainability, and quality of simulation are 
very satisfactory. Specific findings are listed below: 
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h The GMTS response time averaged -1 to 2 seconds. The worst cases* 5 to 8 
seconds, occurred in less than 5 percent of the system r^ponses. 

2. Student acceptance of the touch pen was high. Inputs are definite, as they are 
accompanied by a faint click, and recognition by the GMTS was excellent. 

3. Image quality on the microfiche screen was sensitive to the wear of the plastic 
fiche holders covering each fiche. As the holders became scxat^ed <md opaque from 
wear, the quality of the image deteriorated markedly* While the fiche itself is not 
affected, the holders must be replaced periodically. 

4. Given proper preventive maintenance attention, the microfiche retrieval system 
functioned quietly and smoothly. On occasion, the unit either failed to retrieve and 
project an image or projected a double image. On the average, this occurred approxi- 
mately once for every 2 or 3 hours of use. When this happened, the student could touch 
RENEW IMAGE at the command menu to correct the image projection. There was ho 
instance in which an incorrect image was displayed. 

Support Requirements 

Table i presents projections of subsystem reliability and maintainability for the 
GMTS. The per unit failure rates, m&rtenance times, arid repair costs are based upon 18 
months 1 experience with six units in _a developmental environment and 4 months' 
experience with four units in a training settings 



Table 1 

System Reliability and Maintainability 



< 

Unit 
(Subsystem) 


Projected 
Failures 
Per Year 


Average 
Man-hours 
Per Failure 


Preventive 
Maintenance 
Hours/Year 


Total 
Man-hours 
Per Year 


Projected Parts 
Costs ($) 
Per Year 


Terack System 


1 


8 


T 20 


28 


200 


Graf pen 


i 


10 


10 


20 


100 


Br uriirig 95 


10 


I 


50 


60 


\ 200 


Printer 


1 




16 




50 


System 

(Cables, etc) 


2 


i 


19 




10 


Total 








m 


560 



Reliability of the computer, CRT, disk drives, and touch pen has been excellent; As 
shown in Table J, only two failures per year . are projected for these components. 
Restoration times can average 8 to 10 hours for these failures, assuming that malfiinc- 
tions will most likely occur in the mechanical portion of the disk drive or wiil c be 
intermittent. Hard failure on circuit boards^ however, could be corrected in less than 2 
rx>urs. , 
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The most complex electromechanical device in GMTS is the microfiche retrieval unit, 
which is projected to fail ten times per year. Restoration time is expected to be^short, 
however, as most failures are likely to involve jamming or slippage; 

The 8-inch floppy diskettes have proven to be economical and reasonably durable. 
While extreme abuse will destroy the stored data, instructors can easily copy daily data to 
master diskettes and print hard-copy summaries. Thus, catastrophic losses of student 
data can be prevented. 

Software Transportability * 

The executive and utility programs were fully reprogrammed in UCSD. Pascal. No 
system function required assembly language patches or nonstandard application of the 
language. These source programs have been compiled under the 1.5, H.0, and ILJLversjons 
of the Pascal compiler for the Terak 8510a, the Apple II, and the Altos ASC8000. Since 
UCSD Pascal can be implemented by an increasing number of microcomputers, GMTS 
software can capitalize upon future hardware improvements. The only machine- 
dependent software employed was related to interfacing with the touch input system and 
the microfiche system. 

Instructor Utilities 

The repertoire of utility programs for instructor use was expanded to include 
programs to set up diskettes for-new students, to control problem presentation, and to 
copy, accumulate, and print out student performance data. In addition, utility programs 
were produced for use during data base development. These programs check and reformat 
the raw input data and provide a convenient means for identifying touch points on the 
graphic images. - 

One course has been conducted to train SMEs in data base preparation. . This 
experience indicated that SMEs can be trained in less than 2 weeks to prepare a new data 
base and execute the associated utility programs. 



CONCLUSIONS 

The GMTS hardware and scltware have been refined and documented to meet the 
objectives of this phase of research. The trainer is ready for test and evaluation in a 
Navy school. 

UCSD Pascal is a suitable language for GMTS programming, and such programs are 
transportable to other computers. 

RECOMMENDATIONS 

• The software products that are described in this report are potentially useful to the 
Navy beyond this research. The UCSD Pascal operating system and language should be 
used, along with the GMTS computer programs, for the prototype electronic equipment 
maintenance training (EEMT) system (Device 11B106), which is being developed for 
initial-skills training of electronic technicians and electronic warfare operators. While 
the data base that simulates the AN/WSC-3 Was developed for advanced-skills gaining, it 
could be modified for use by the EEMT project. Different malfunctions would have to be 
simulated, but the normal operations data base could be used intact. The microfiche 



photographs would have to be replaced with media that are compatible with Device 
i IB 1 Q6, which uses videodisc. 

Numerous questio^ pedagogical approaches and 

design alternatives for general-purpose maintenance simulators remain to be addressed by 
future research: 

L Train: hg effectiveness . Before the training effectiveness of general-purpose 
maintenance trainees can be determined, the following pedagogical issues should be 
addressed: : 

a. the amount of student control that is optimal in various situations. 

b. The types of support and aiding that should be provided. 

c. • How effectively an intelligent trainer can adapt to particular student needs 
(beyond pace 6f training and problem selection). 

> _ _ 
Many of these pecfegbgical issues are «itwiried with design variables. For example, 
we n§§§ to know tfie ^relative advantage and disadvantages of a single display trainer and 
how data base preparation cost is affected by computer-generated graphics. 

2. Fidelity . Research should be conducted Jo det^mine Jhe need f or three- 
dimensional maintenance simulators, which are realistic physical sinr^ations of the read 
equipment. At a middle point on the realism continuum are hybrid trainers, which offer 
hands-on use of actual test eqtipment in association with •'flat-panel" or twcFcQmensional 
simulation of" the l^s universal real equipment. Such cdrnbiilatiohs may provide a very 
attractive comKhatibh of cognitive exercise and procedural drill arid practice. 

3. Representation. The process of ^preparing data _ bases for GMTS should be 
streamlined. Since much of that process is clerical, c computer-aided approach may yield 
considerable savings. 

■ 1_ 4. Application . We should learn more about the domain of the GMTS approach. 
The only assumption made about the inherent nature of the simtUatedjequipment is that it 
can exist in a number of discrete states. Experience with applying GMTS to three large 
electronic systems indicates that jt insufficiently general to ^commodate nearly 111 

: electric and electronic amtHations. Those functions that do hot strictly meet the * 

assumptions ran almost always be reduced or Restricted hi ways that impose minimal 
artificiality. For example, a rontinuously-reading meter can^ be defined asr-lndicating a 
small number of values, such as 0, low, normal, high, and maximum. I 

One question that remains is the extent to which nonelectronic systems could be 
accommodated; that is, whether automatic boilers^ engines, ^terina mounts, and helicop- 
ter control mechanisrhs could be represented adequately by this finite-state model. If 
pot, what is the nature of the delation, and could further generalization r^blve the 
problems? 

5. Job-perf ormance measures . At the heart of all these questions^ is the issue of 
sensitivity of job performance to various training alternatives. As yet, no data are 
available that relate the effectiveness of simulation-based maintenance training to on- 
the-job perf brriiance. 
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APPENDIX 

SUMMARY COMPUTER PROGRAM DOCUMENTATION 



ERLC 



27 

A-0 



SUMMARY COMPUTER PROGRAM DOCUMENTATION 
Name of Program; TRAINER 

Purpose; This program drives a prototype computer-based training system known as 
the Generalized Maintenance Trainer Simulator (GMTS) or Rigney Trainer, a device that 
is currently used to simulate electronic equipment maintenance. Simulation is achieved 
by displaying One of a number of photographs of the equipment with a microfiche 
projector; interface with the user occurs via the projector, a sonic pen, and the CRT. A 
data base file contains a complete description of the equipment, simulated faults in the 
equipment, and a listing of the photographs, thus making TRAINER independent of the 
equipment that it simulates.; 

Hardware requirements; UCSD Pascal (TM) Operating system version 1.5, Bruning 
model 95 microfiche projector, Science Accessories Corporation Graf pen, and a Terak 
8510 computer and 8512 disk drive. The source code has also been compiled under 
versions n.O and H.i of UCSD Pascal. 

Documentation; Fully documented. 

Comments; Four other programs related to the trainer system are available; 

1. XY— Computes coordinates of touch points on the trainer panel. 

2. PREPROCESS— Processes the alphanumeric data base (entered using the Pascal 
editor) into the format required by TRAINER. 

3. UTILITY— General utility routines for "disk initialization, etc. 

4. DATACK— Data base checkout/verification program. 

********** 

Name of Program; XY 

Purpose; This program is to be used in conjunction with the TRAINER program to 
compute the coordinates of legitimate sonic pen touch points on the front panel of the 
trainer simulator. New touch points may be defined or old point positions revised; the 
'results are stored in the file RTXYDATA.DATA for use by TRAINER. 

Hardware Requirements; Same as for TRAINER. 



Documentation; Fully documented. 

********** 



Name of Program; PREPROCESS. 

Purpose: This program is to.be used in conjunction with the TRAINER program to 
process the alphanumeric data base. It processes a data base created using the Pascal 
long-text editor (L2) to create the file RTDATA.DATA, which is used by TRAINER. 

Hardware Requirements; UCSD Pascal (TM) operating system. 
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Docume ntati o n ; Fully documented. 



********** 



Name of Program; UTILITY 

Purpose; This program is,;to Be used in conjunction with the TRAINER program to 
provfde^essary utili^ routines for GMTS. Such routines include disk initialization, 
problem sequence selection, current sequence examination, student performance print- 
outs, and a master copy routine. 

Hardware Requirements UCSD Pascal (TM) operating system; 
Documentation; Fully documented. 



********** 



BATACK 

Purpose; This program is to be used in conjunction with the TRAINER program to 
verifTthffegical correctness of the dcta base used in the GMTS. It directs to the screen 
da*a that TRAINER would ordinarily se.->d to the microfiche projector and reads its input 
from the keyboard rather than from a sonic pen. This allows a user who is familiar with 
the data base to trace errors made in preparing the data. 

Hardware Requirements; UCSD Pascal (TM) operating system, version 1.5, Terak 
8510 computer with an S512 disk drive, and a Science Accessories Corporation sonic 
Graf pen; 

Documentation; Fully documented. 
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